🚪 Lambda 沒有網址，需要一個前門

Day 18 的 Lambda 能執行程式碼，但它本身沒有 HTTP 端點——前端沒有網址可以打。API Gateway 補上這一塊：接收 HTTP 請求、做認證與流量控管、再呼叫後端的 Lambda（或其他服務），把回應送回去。這是打造無伺服器 API 最常見的組合。

🧭 三種 API 類型

API Gateway 底下其實是三個功能不同的產品，選錯類型會多付不必要的成本或少掉需要的功能：

沒有特殊需求，新專案預設選 HTTP API：便宜、延遲低，覆蓋大多數「前端呼叫 Lambda」的情境。要用到 REST API 才有的功能（例如請求/回應轉換、API key 配額管理）才選 REST API。

🔌 兩種整合方式

Lambda 掛到 API Gateway 後面，有兩種串接方式：

沒有特別理由，直接用 Proxy 整合：設定少一層，程式碼邏輯集中在 Lambda，不用另外學 mapping template 語法。

🛡️ 誰能呼叫：認證方式

API Gateway 不會自己決定「誰可以打這個 API」，要另外掛認證機制：

Amazon Cognito 簡單說是受管的使用者身份服務：User Pool 負責使用者註冊、登入、簽發 token；Identity Pool 則是讓前端用已登入的身份換取臨時 AWS 憑證，直接存取 S3、DynamoDB 這類 AWS 資源。API Gateway 搭配的通常是 User Pool——使用者登入拿到 token，之後每次呼叫 API 帶著這個 token，Cognito 授權方幫忙驗證。

🧰 其他常用功能

⏱️ 處理時間長的請求：整合逾時與非同步處理

API Gateway 呼叫後端之後，只會等待一段固定的時間，稱為整合逾時（integration timeout）。超過這個時間，API Gateway 就停止等待，回傳 504 錯誤給前端：

Day 18 的 Lambda 最長可以執行 15 分鐘，所以一個要跑 3 分鐘的 Lambda 仍然會執行完畢，但前端在逾時的那一刻就已經收到 504 錯誤，拿不到結果。

因此處理時間長的工作，例如產生報表、影片轉檔，不適合讓前端一直等 API 回應。常見的做法是改成非同步處理：

1. 前端呼叫 API，API Gateway 把這項工作寫成一則訊息放進 SQS（API Gateway 可以直接整合 SQS，不需要經過 Lambda）
2. API Gateway 立刻回應前端「已收到」，並附上這則訊息的編號
3. 背景的 Lambda 從 SQS 取出工作處理，把結果寫進 DynamoDB 或 S3
4. 前端之後用編號查詢結果

判斷方式：使用者必須拿到結果才能繼續的請求，例如查詢訂單、登入，走同步的 API Gateway → Lambda；處理時間長，或結果不需要立刻回傳的工作，改成非同步，由 SQS（Day 16）在背景緩衝。

📌 補充

✅ 小結

摘要：API Gateway 是無伺服器 API 的入口，負責 Lambda 做不到的事：認證、流量控管、格式轉換。新專案預設選 HTTP API，終端使用者登入用 Cognito authorizer。整合逾時約 30 秒，處理時間長的工作要改成透過 SQS 非同步處理。

🧠 AI 出題

問題 1

某新創公司正在為行動 App 建立後端 API，所有端點都以 Lambda proxy 整合處理。使用者透過 Amazon Cognito User Pool 登入，API 必須驗證請求帶的 JWT，而且驗證要在進入 Lambda 之前統一完成，不寫在各函式的程式裡。目前不需要回應快取、API key 或請求格式轉換，預估每月有數億次請求。公司希望以最符合成本效益（MOST cost-effective）的方式建置。

解決方案架構師應該怎麼做？

• A. 建立 REST API，以 Cognito User Pool authorizer 驗證 token，並用 Lambda proxy 整合呼叫後端
• B. 建立 REST API 並啟用 API key 與 usage plan，由各 Lambda 在程式中驗證 Cognito 發的 JWT
• C. 為每個 Lambda 開啟 function URL，並在每個函式的程式碼中各自驗證 Cognito 發的 JWT
• D. 建立 HTTP API，設定以 Cognito User Pool 為 issuer 的 JWT authorizer，再整合 Lambda

問題 2

某公司要把商品查詢 API 開放給 30 家合作電商呼叫。每家的合約方案不同：基本方案每天最多 1 萬次、每秒 10 次；進階方案每天最多 10 萬次、每秒 100 次。公司需要能區分每一家的呼叫量，並自動套用各自方案的限制，同時希望以維運負擔最低（LEAST operational overhead）的方式完成。

哪一個方案能以最低的維運負擔滿足需求？

• A. 建立 HTTP API 並在每條 route 設定 throttling，再由 Lambda 依來源 IP 判斷是哪一家合作夥伴
• B. 建立 REST API，為每家發一組 API key，依方案建立兩個 usage plan 設定配額與速率並綁定 key
• C. 在 API 前面加上 AWS WAF，為每家合作夥伴的 IP 建立 rate-based rule 限制每 5 分鐘的請求數
• D. 撰寫 Lambda authorizer，在 DynamoDB 記錄每家每天的呼叫次數，超過合約上限就拒絕請求

問題 3

某公司帳號 A 的訂單服務跑在 Amazon ECS 上並使用 IAM task role，它需要呼叫帳號 B 以 API Gateway REST API 提供的庫存 API。資安團隊要求：只有帳號 A 的這個 task role 能呼叫，不能使用任何長期有效的共享密鑰，而且每次呼叫都要能追溯到呼叫者的 IAM 身分。公司希望以最安全（MOST secure）的方式設計。

解決方案架構師應該採取哪兩項做法？（選擇兩項）

• A. 為 API 的方法啟用 IAM 授權，並在 resource policy 中只允許帳號 A 的 task role 呼叫
• B. 在帳號 A 的 task role 加上允許 execute-api:Invoke 這個 API 的政策，服務以 SigV4 簽章呼叫
• C. 建立一組 API key 存進帳號 A 的 Secrets Manager，要求服務每次呼叫時都在 header 帶上這組 key
• D. 在帳號 B 的 Cognito User Pool 為訂單服務建立一個使用者帳號，服務以帳密登入取得 token 後再呼叫
• E. 撰寫 Lambda authorizer 比對 header 中的共享密鑰，並每季手動輪替密鑰、通知帳號 A 更新設定

問題 4

某公司用 API Gateway HTTP API 搭配 Lambda 提供「產生年度報表」的端點，報表要彙整大量資料，每次處理約 2～5 分鐘。使用者按下按鈕後，總是在約 30 秒時收到逾時錯誤，但 Lambda 的日誌顯示報表其實都有產生成功。公司希望使用者不再看到錯誤、能在報表完成後拿到下載連結，並以最少的架構改動完成。

哪一個做法最符合這些需求？

• A. 把 Lambda 的 timeout 調到 15 分鐘，並把 HTTP API 的整合逾時同步調高到 10 分鐘
• B. 為 Lambda 設定 provisioned concurrency，消除 cold start 來縮短每次產生報表的處理時間
• C. 讓端點把請求送進 SQS 後立即回傳工作 ID，由另一個 Lambda 產生報表，前端再依 ID 查詢進度
• D. 把 HTTP API 改寫成 WebSocket API，讓連線一直保持到報表完成，再把下載連結推送給前端

問題 5

某相簿 App 的使用者以 Amazon Cognito User Pool 登入。公司希望使用者能直接從 App 把照片上傳到 S3，而且每位使用者只能寫入 bucket 中以自己的身分 ID 為前綴的路徑。照片常常超過 10 MB，公司要求檔案不經過自家後端轉送，並以最安全的方式設計。

解決方案架構師應該怎麼做？

• A. 在 App 中內建一組 IAM user 的 access key，再以 bucket policy 依請求中的使用者 ID 限制可寫入前綴
• B. 設定 Cognito Identity Pool 以 User Pool 的 token 換取臨時憑證，IAM 政策用身分變數限制前綴
• C. 讓 App 把 User Pool 發的 ID token 放在 S3 PUT 請求的 header 裡，由 S3 驗證 token 後寫入
• D. 建立 API Gateway 與 Lambda 的上傳 API，由 Lambda 接收照片內容後以自己的 role 寫入 S3

💡 解答

1. D

HTTP API 的單價大約只有 REST API 的三成，而且內建 JWT authorizer：把 Cognito User Pool 設成 issuer，API Gateway 會在呼叫 Lambda 之前先驗證 token，驗證失敗的請求根本不會進到 Lambda。題目不需要快取、API key、格式轉換這些 REST API 才有的功能，每月數億次請求的規模下，HTTP API 是最省的選擇。

A 功能上完全符合，但 REST API 的單價是 HTTP API 的三倍多，用不到它多出來的功能，就是在多付錢。B 把驗證寫進各個 Lambda，違反「在進入 Lambda 之前統一完成」；API key 也只能識別呼叫方，不是用來驗證使用者身分的。C 的 function URL 本身不收費，看起來最省，但它沒有 JWT authorizer，驗證只能寫進每個函式，同樣違反要求。

2. B

usage plan 就是為了「把 API 開放給多個外部客戶、各自有配額」而設計的：每家合作夥伴發一組 API key，依方案建立兩個 usage plan，各自設定每天的配額（quota）和每秒的速率與突發上限（throttling），再把 key 綁到對應的 plan。超過限制的請求會被 API Gateway 直接擋下，完全不用寫程式。usage plan 只有 REST API 支援。

A 是誤解：HTTP API 沒有 usage plan 和 API key，只能設定整條 route 的限流，沒辦法依客戶區分；而且用來源 IP 辨識客戶並不可靠。C 的 WAF rate-based rule 是依 IP 在一段時間內的請求數計算，沒有「每天幾次」這種配額，也沒辦法依合約方案分組。D 能做到，但等於自己實作 usage plan，還要處理計數的並發寫入和每天重置，維運負擔最高。

3. A、B

IAM 授權要求呼叫方用 AWS 憑證以 SigV4 簽章請求。ECS 的 task role 本身就提供會自動輪替的臨時憑證，沒有任何長期密鑰。跨帳號呼叫時兩邊都要放行：帳號 B 在 API 的 resource policy 裡只允許帳號 A 的那個 task role，帳號 A 也要在 task role 上允許 execute-api:Invoke，少了任何一邊都會被拒絕。每次呼叫都會以呼叫者的 IAM 身分記錄下來，可以追溯。

C 是常見的誤解：API key 是用來識別呼叫方、搭配 usage plan 做配額的，不是身分驗證機制，而且它本身就是一組長期有效的共享密鑰。D 讓服務用帳號密碼登入，密碼一樣是長期密鑰；Cognito User Pool 是給終端使用者登入用的，拿來做服務對服務的驗證既不自然也不安全。E 的共享密鑰直接違反要求，手動輪替也容易出錯。

4. C

HTTP API 的整合逾時上限是 30 秒，而且不能調高，所以只要後端處理超過 30 秒，使用者就一定會收到逾時錯誤。報表需要 2～5 分鐘，正確的做法是改成非同步：端點只負責把請求放進 SQS 並立刻回傳工作 ID，另一個 Lambda 在背景產生報表，前端再依工作 ID 查詢進度、取得下載連結。原本的 HTTP API 和 Lambda 都保留，只是拆開成「接單」和「處理」兩段，改動最小。

A 是誤解：Lambda 的 timeout 可以調到 15 分鐘，但 HTTP API 的整合逾時最多只有 30 秒，沒有辦法調高到 10 分鐘。B 解的是 cold start，但這裡慢的是報表本身要跑幾分鐘，不是初始化。D 技術上可以做到推送，但要把整個 API 改寫成 WebSocket，前端也要改成維護長連線，改動遠大於 C。

5. B

Cognito Identity Pool 可以用 User Pool 簽發的 token 換取一組有時效的 AWS 臨時憑證，App 就能直接呼叫 S3 上傳，大檔案不用經過自家後端。IAM 政策可以用身分變數（例如 ${cognito-identity.amazonaws.com:sub}）限定資源路徑，每位使用者只拿得到寫入自己前綴的權限，是最安全的做法。

A 把長期有效的 access key 放進 App，任何人拆開 App 就能拿到金鑰，而且請求中的「使用者 ID」由用戶端自己填寫，可以偽造。C 是誤解：S3 不會驗證 Cognito User Pool 的 token，要存取 S3 必須有 AWS 憑證簽章，User Pool 的 token 要先透過 Identity Pool 換成臨時憑證。D 讓所有照片都經過 API Gateway 和 Lambda 轉送，違反「不經過自家後端」；API Gateway 的請求大小上限是 10 MB，超過 10 MB 的照片根本傳不上去。